Virtualisation and cloud computing have vastly improved our ability to experiment and innovate, especially at scale. In this talk, I hope to show you that experimentation is so cheap that anybody can (and should) have a go. We’ll see how docker can be used to try out new products and technologies in a rapid and repeatable fashion, and I’ll also be demonstrating a couple of basic techniques for rapidly (but flexibly) deploying Docker that should be useful when the focus of your experiments is Docker itself.
Bio: Adam works for Dimension Data's R&D division as a professional dilettante - he does a little bit of everything, and likes it that way. Other interests include hiking, kayaking, writing electronic music, mountain biking, and fridge poetry.
4. What this talk is about
» Experimenting with Docker (der)
5. What this talk is about
» Experimenting with Docker
» Using virtualisation to reduce cycle time when
trying out ideas
6. What this talk is about
» Experimenting with Docker
» Using virtualisation to reduce cycle time when
trying out ideas
» Using the cloud to achieve scale
7. What this talk is about
» Experimenting with Docker
» Using virtualisation to reduce cycle time when
trying out ideas
» Using the cloud to achieve scale
» Without breaking the bank
9. What I'd like to leave you with
1. We learn more from our failures than our successes
10. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor
11. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor (prefer to minimise variables)
12. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor
» Aim for repeatability where possible
13. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor
3. Virtualisation + automation make it cheap to
experiment
14. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor
3. Virtualisation + automation make it cheap to
experiment
4. If experimentation is cheap enough, you can try out
almost any idea you can come up with
15. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor
3. Virtualisation + automation make it cheap to
experiment
4. If experimentation is cheap enough, you can try out
almost any idea you can come up with
» Think it's a silly idea? Prove it.
16. What I'd like to leave you with
1. We learn more from our failures than our successes
2. Occam's razor
3. Virtualisation + automation make it cheap to
experiment
4. If experimentation is cheap enough, you can try out
almost any idea you can come up with
» Don’t be afraid to experiment!
17. Why I love Virtualisation
Virtualisation is the bedrock on which most things cloud
are built.
18. Why I love Virtualisation
Virtualisation is the bedrock on which most things cloud
are built.
It is the key to:
»
19. Why I love Virtualisation
Virtualisation is the bedrock on which most things cloud
are built.
It is the key to:
» Economies of scale
20. Why I love Virtualisation
Virtualisation is the bedrock on which most things cloud
are built.
It is the key to:
» Economies of scale
» Speed of provisioning
21. Why I love Virtualisation
Virtualisation is the bedrock on which most things cloud
are built.
It is the key to:
» Economies of scale
» Speed of provisioning
» Repeatability
22. Why I love Virtualisation
Virtualisation is the bedrock on which most things cloud
are built.
It is the key to:
» Economies of scale
» Speed of provisioning
» Repeatability
» The ability to readily and reliably duplicate an
environment and its resources
23. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
24. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do
25. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do, rather than how to do it
26. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do, rather than how to do it
» Economies of scale also come into play:
27. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do, rather than how to do it
» Economies of scale also come into play:
» You can’t fit 20 servers under your desk
28. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do, rather than how to do it
» Economies of scale also come into play:
» You can’t fit 20 servers under your desk, but your
cloud provider has plenty to spare (for as long as
you need them)
29. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do, rather than how to do it
» Economies of scale also come into play:
» Most providers now charge only for what you
actually use
30. Why I love the concept of Cloud
For all its potential downsides, the cloud has vastly
improved the process of experimentation:
» By selectively abstracting away levels of
infrastructure, it enables us to focus on what we're
trying to do, rather than how to do it
» Economies of scale also come into play
» Lower costs make it easier to explore a problem
space, which helps to mitigate risk
31. Experimenting in the cloud
The trick to being productive when experimenting in the
cloud:
» Get set up
32. Experimenting in the cloud
The trick to being productive when experimenting in the
cloud:
» Get set up
» Do your experiment
33. Experimenting in the cloud
The trick to being productive when experimenting in the
cloud:
» Get set up
» Do your experiment
» Clean up the evidence
34. Without breaking the bank
The trick to being productive when experimenting in the
cloud:
» Get set up
» Do your experiment
» Clean up the evidence
» Before the mob arrives with pitchforks and flaming
torches
36. If you've heard of it, there's probably a Docker image of it.
37. If you've heard of it, there's probably a Docker image of it.
Example: What’s Neo4J?
38. If you've heard of it, there's probably a Docker image of it.
Example: What’s Neo4J?
docker run -p 7474:7474 neo4j
39. If you've heard of it, there's probably a Docker image of it.
Ok, how about RabbitMQ?
40. If you've heard of it, there's probably a Docker image of it.
Ok, how about RabbitMQ?
docker run -p 5672:5672 rabbitmq
41. If you've heard of it, there's probably a Docker image of it.
Ok, smartarse
42. If you've heard of it, there's probably a Docker image of it.
Ok, smartarse, but I bet there isn't one for cowsay
43. If you've heard of it, there's probably a Docker image of it.
Ok, smartarse, but I bet there isn't one for cowsay
docker run mwendler/cowsay "Sorry."
46. That's super useful, but what if you're experimenting with
docker itself?
docker-machine create docker1
eval $(docker-machine env docker1)
47. That's super useful, but what if you're experimenting with
docker itself?
docker-machine create docker1
eval $(docker-machine env docker1)
Ok, but not very cloudy.
48. That's super useful, but what if you're experimenting with
docker itself?
How about:
49. That's super useful, but what if you're experimenting with
docker itself?
How about:
docker-machine create --driver amazonec2 docker1
docker-machine create --driver amazonec2 docker2
51. That's super useful, but what if you're experimenting with
docker itself?
Or:
docker-machine create --driver digitalocean docker1
docker-machine create --driver digitalocean docker2
54. Docker Machine is nice, but it's opaque
Sometimes that’s what you want.
55. Docker Machine is nice, but it's opaque
Sometimes that’s what you want (again, the focus may be
on what you're trying to do).
56. Docker Machine is nice, but it's opaque
Sometimes that’s what you want (again, the focus may be
on what you're trying to do, not how).
57. Docker Machine is nice, but it's opaque
Sometimes that’s what you want (again, the focus may be
on what you're trying to do, not how).
Other times, not so much.
58. Docker Machine is nice, but it's opaque
Sometimes that’s what you want (again, the focus may be
on what you're trying to do, not how).
Other times, not so much.
So what other options are there?
59. Do it by hand
You could do this at least once - a useful learning
experience (especially for when things go wrong).
61. Infrastructure with Terraform
Declarative configuration for infrastructure
» Multi-cloud / multi-provider
» Repeatable
» Easy to consistently create / destroy / re-create
infrastructure
But Terraform is only half the story. Once the infrastructure
has been created, how do you get Docker itself deployed
and configured?
62. Software with Ansible
» Hardly the only option out there, but if you're
experimenting with throw-away systems then it's a good
choice because it's just SSH (no master / agents to deploy)
» Chef Solo (or Chef Zero) is an alternative, but may still
require more work to bootstrap each node
» Quick to get started (just run commands or modules on
target machines)
» Scales up to Roles + Playbooks for repeatability
» Not great for managing large numbers of machines
63. Software with Ansible
» Can be run from Terraform (via a plug-in provisioner) but
it's a lot easier to run it separately while you're
experimenting.
» There are Ansible inventory plugins that can read a
Terraform state file (so it knows server roles, host names,
IP addresses, etc).
» Ansible Galaxy has modules for everything, including
Docker (hint, hint)
» Beware if you are deploying an OS with only Python 3.x
(Ansible needs 2.x)
64. A quick detour:
Docker from simple to complex
» Stand-alone
» Docker
» Orchestrated
» Local
» Docker Compose
» Clustered
» Docker Swarm
» Clustered with GUI
» Cattle / Rancher
» Kubernetes
» Mesos / Marathon
» Kitchen Sink
» Mantl
Note that simple and easy-to-use are not the same thing :)
65. Cisco Mantl
» Mantl is a microservices platform based on Docker,
Mesos / Marathon, Consul, Traefik, Kubernetes, Calico,
Contiv, etc (pretty much everything but the kitchen sink).
» Because it already includes several popular systems that
extend / orchestrate Docker, it’s a useful starting point if
you’re stuck trying to work out how to deploy or
integrate a particular component
66. Cisco Mantl
» Mantl is deployed using Terraform with Ansible, and can
therefore be deployed on a variety of clouds by
swapping out Terraform modules as required.
» Their Ansible inventory plugin understands which cloud
provider was used to create the infrastructure and so
Ansible playbooks can adjust their behaviour to suit (if
required).
69. Build your own (throw-away) lab
» Digital Ocean is fast
Add Terraform and you can repeatedly create and
destroy environments in seconds, rather than minutes.
» Obviously you can use AWS / Azure, too (or
Dimension Data Cloud Control) but for quick-and-dirty
experiments I prefer the simplest thing that works).
» Create an Ansible playbook to install Docker
» Start small - put everything in a single playbook and
then move stuff out to separate reusable roles when
needed
70. Build your own lab
4 servers (1 master, 3 workers).
lab.tf:
resource "digitalocean_droplet" "master" {
count = 1
image = "ubuntu-14-04-x64"
name = "master-${count.index + 1}"
region = "nyc2"
size = "1024mb"
}
resource "digitalocean_droplet" "worker" {
count = 4
image = "ubuntu-14-04-x64"
name = "worker-${count.index + 1}"
region = "nyc2"
size = "1024mb"
}
74. Build your own lab
» terraform apply
» …
» Profit!
» terraform destroy
75. Build your own lab
» terraform apply
» …
» Profit!
» terraform destroy
» No pitchforks
76. Build your own lab
» terraform apply
» …
» Profit!
» terraform destroy
» No pitchforks (probably)
77. Why not use Rancher / Docker Cloud?
» If all you want to do is deploy containers then these
are a much better choice
78. Why not use Rancher / Docker Cloud?
» If all you want to do is deploy containers then these
are a much better choice
» Rancher uses docker-machine to create nodes for
you
79. Why not use Rancher / Docker Cloud?
» If all you want to do is deploy containers then these
are a much better choice
» Rancher uses docker-machine to create nodes for
you
» But this is a good choice if you want to learn about:
80. Why not use Rancher / Docker Cloud?
» If all you want to do is deploy containers then these
are a much better choice
» Rancher uses docker-machine to create nodes for
you
» But this is a good choice if you want to learn about:
» How to deploy docker
81. Why not use Rancher / Docker Cloud?
» If all you want to do is deploy containers then these
are a much better choice
» Rancher uses docker-machine to create nodes for
you
» But this is a good choice if you want to learn about:
» How to deploy docker
» Non-standard docker configurations
82. Why not use Rancher / Docker Cloud?
» If all you want to do is deploy containers then these
are a much better choice
» Rancher uses docker-machine to create nodes for
you
» But this is a good choice if you want to learn about:
» How to deploy docker
» Non-standard docker configurations
» It's useful to have a feeling for what's behind the UI