While working on Docker for AWS and Azure, we realized the need for a standard way to create and manage infrastructure state that was portable across any type of infrastructure, from different cloud providers to on-prem. One challenge is that each vendor has differentiated IP invested in how they handle certain aspects of their cloud infrastructure. It is not enough to just provision five servers; what IT ops teams need is a simple and consistent way to declare the number of servers, what size they should be, and what sort of base software configuration is required. And in the case of server failures (especially unplanned), that sudden change needs to be reconciled against the desired state to ensure that any required servers are re-provisioned with the necessary configuration. We started InfraKit to solves these problems and to provide the ability to create a self healing infrastructure for distributed systems.

1. InfraKit
Bill Farner
David Chung

2. mission
make Docker cluster infrastructure
as simple and portable as Docker applications

3. avoid silos
ACS setup routine
ACS runtime system
Docker for ACS UX
AWS setup routine
AWS runtime system
Docker for AWS UX

4. common parts
setup routine
runtime system
Docker UX
AWS
adapter
ACS
adapter

5. ...most of this isn’t Docker-specific

6. mission, revised
make Docker cluster infrastructure
as simple and portable as Docker applications

7. tl;dr InfraKit is...
a toolkit for infrastructure orchestration

8. tl;dr InfraKit is...
a toolkit for infrastructure orchestration
‘scaling groups’ for any environment

9. tl;dr InfraKit is...
a toolkit for infrastructure orchestration
‘scaling groups’ for any environment
young

10. what InfraKit is not
coupled to Docker

11. what InfraKit is not
coupled to Docker
a configuration management system (e.g. Terraform)

12. what InfraKit is not
coupled to Docker
a configuration management system (e.g. Terraform)
a Swarm / Kubernetes alternative

13. why InfraKit is special
declarative state

14. why InfraKit is special
declarative state
continuous monitoring and reconciliation

15. why InfraKit is special
declarative state
continuous monitoring and reconciliation
bias towards immutable infrastructure

16. toolkit
primitives for managing groups of resources
a collection of components as plugins
abstractions, patterns, and APIs

17. plugin types
instance: a resource (e.g. EC2 instance)
group: a collection of 'like' resources (e.g. ASG)
flavor: modification to an Instance (e.g. swarm join)

18. plugin responsibilities
group
watch, unwatch, destroy, update
flavor
prepare, health, drain
instance
provision, destroy

19. defining useful and flexible abstractions
start with high-level nouns and verbs
avoid rigid schemas causing lowest common denominators

20. abstract schemas
{
“Plugin”: “”,
“Properties”: {..}
}
$ grep -RI json.RawMessage . --exclude-dir vendor/ | wc -l
132

21. ...until the problem domain
type CreateInstanceRequest struct {
RunInstancesInput ec2.RunInstancesInput*
}
request := CreateInstanceRequest{}
err := json.Unmarshal(*spec.Properties, &request)
* github.com/aws/aws-sdk-go/tree/master/service/ec2

22. {
"ID": "group-name",
"Properties": {
"Allocation": {..},
"Instance": {
"Plugin": "instance-plugin-name",
"Properties": {..}
},
"Flavor": {
"Plugin": "flavor-plugin-name",
"Properties": {..}
}
}
}

23. {
"ID": "group-name",
"Properties": {
"Allocation": {..},
"Instance": {
"Plugin": "instance-plugin-name",
"Properties": {..}
},
"Flavor": {
"Plugin": "flavor-plugin-name",
"Properties": {..}
}
}
}

24. {
"ID": "group-name",
"Properties": {
"Allocation": {..},
"Instance": {
"Plugin": "instance-plugin-name",
"Properties": {..}
},
"Flavor": {
"Plugin": "flavor-plugin-name",
"Properties": {..}
}
}
}

25. {
"ID": "nginx",
"Properties": {
"Allocation": { "Size": 3 },
"Instance" : {
"Plugin": "instance-vagrant",
"Properties": { "Box": "ubuntu-docker" }
},
"Flavor" : {
"Plugin": "flavor-vanilla",
"Properties": {
"Init": "docker run -d -p 80:80 nginx-alpine"
}
}
}
}

26. Usage:
infrakit group [command]
Available Commands:
describe-update describe the steps to perform an update
destroy destroy a group
inspect inspect a group
ls list groups
stop-update stop updating a group
unwatch unwatch a group
update update a group
watch watch a group

27. let’s make a Docker cluster!

28. the goal
2 self-healing groups
auto-attached EBS volumes
high availability
cluster VPC
manager security group
manager
docker
infrakit
EBS
manager
docker
infrakit
EBS
manager
docker
infrakit
EBS
worker security group
worker
docker
worker
docker
worker
docker

29. plugins used
group
flavor-combo
instance-aws
flavor-vanilla flavor-swarm

30. behind the scenes
group
instance-aws
start watching
flavor-combo
flavor-vanilla flavor-swarm

31. behind the scenes
group
instance-aws
list instances
flavor-combo
flavor-vanilla flavor-swarm

32. behind the scenes
group
instance-aws
prepare instance flavor-combo
flavor-vanilla flavor-swarm

33. behind the scenes
group
instance-aws
prepare instance
flavor-combo
flavor-vanilla flavor-swarm

34. behind the scenes
group
instance-aws
prepare instance
flavor-combo
flavor-vanilla flavor-swarm

35. behind the scenes
group
instance-aws
fetch join
token
docker
flavor-combo
flavor-vanilla flavor-swarm

36. behind the scenes
group
instance-aws
create
instance
flavor-combo
flavor-vanilla flavor-swarm

37. if InfraKit creates resources...
what creates InfraKit?

38. cluster VPC
manager security group
manager
docker
infrakit
EBS
manager
docker
infrakit
EBS
manager
docker
infrakit
EBS
worker security group
worker
docker
worker
docker
worker
docker

39. bootstrap
AWS resources
- IAM role
- network
- EBS volumes
seed instance
- docker swarm init
- InfraKit
- configs
- plugins
- group watch
github.com/docker/infrakit.aws/tree/master/experimental/bootstrap
cluster VPC
manager security group
EBS
manager
docker
infrakit
EBS
EBS
worker security group

40. demo

41. github.com/docker/infrakit