Audience: Beginner – Intermediate About: In today’s world of agile IT containers have become the new buzz word just like cloud was a few years back. Why would we move our applications to containers? What is the business and operational enhancements can I expect? What are some real world problems with using containers in anger? Speaker Bio: Scott Coulton – DevOps Solution Architect, Health Direct Scott Coulton is a solutions architect with 10 years of experience in the managed services and hosting space. He has extensive experience in architecture, and rolling out systems and network solutions for national and multinational companies with a wide variety of technologies, including AWS, Puppet, Docker, Cisco, VMware, Microsoft and Linux. His design strengths are in cloud computing, automation and the security space. OpenStack Australia Day - Sydney 2016 https://events.aptira.com/openstack-australia-day-sydney-2016/

1. Why
containerise
your life ?

2. The agenda
● So you decided to use containers
● The pitfalls of starting to use containers
● We have the solution to that problem
● Is this ready for production ?

3. Have you ever danced with the devil in the pale
moonlight ?

4. The devil does not change, he changes you
Quote “The Joker, Batman 1989”
This quote is so relevant when starting out with containers.
If you want to be successful you have to change the way you
think about solutions, your operational processes and CD/CI
pipelines. Trying to fit old solution methodology will cause
you technical debt.

5. So you decided to use containers

6. Where do you start ?
So there is a lot of buzz around containers at the moment.
So why should you spend the time and money to move your
applications to containers ?
We will answer this question from three different
perspectives
● The Dev
● Infrastructure
● The business

7. The dev
Why would Dev’s want to use containers ?
● Quick build times
● Run code locally that is the same code as production
● More efficient unit test cycles
● The container becomes the artifact
● Makes the CD/CI process simple

8. Infrastructure
So what about the infra guys and girls ?
● The application is abstract from the host operating
system
● In true ‘devops’, it’s infra as code
● It creates a collaborative environment
● Brings down operational overhead
● Makes the CD/CI process simple

9. The business
It’s all about the bottom dollar, so how do we justify the
change
● Collaboration breeds efficiency
● Increased quality of releases
● Containers are platform agnostic
● Language agnostic

10. Where do we start
Now we see the benefits, where do we start ?
● Pick a small application or service
● Make sure it works
● Gain business trust

11. The pitfalls of starting to use containers

12. It can’t be all fairy floss and rainbows
Now we have a few ideas of services or apps to containerise.
What real world issues will come up.
● Do we run 1 container per compute resource
● Where does our data or state reside
● How do we handle failures
● What about the way my data is structured

13. Do we run 1 container per compute resource ?
If we run containers 1:1 with compute resources what’s the
point ?
● So we need a solution to scale
That word ‘scale’ needs to be defined
● Are we talking on the same compute resource
● Does this mean across AZ’s
● What about completely different datacentres
What about application routing within a compute resource ?

14. Where does our data or state reside ?
Containers and stateless services are like a mirage in
heaven. Unfortunately not all applications can be stateless.
So how do we handle this ?
● Should the data live inside the container
● Maybe map a drive to the compute resource
● Can we split the compute from the state

15. How do we handle failures
What happens to application failure within a container ?
● How can we design for failure
● What measures can we put in place to prevent failure
● Can we auto heal containers

16. How do I structure my data
There are so many moving parts to building an image,
creating the container and the release process.
● What configuration lives where
● How can I test my container
● With so many parts what does my source control structure
look like

17. We have the solution to that problem

18. This is how we scale
So let’s define scale !!!
For the same for the same compute node we have to following
options
● Docker Compose https://docs.docker.com/compose/

19. This is how we scale
For more complex scaling needs like across multiple compute
nodes or AZ’s. We would use a container scheduler.
● Docker Swarm https://docs.docker.com/swarm/
● Google’s Kubernetes http://kubernetes.io/
● Apache Mesos https://mesos.apache.org/
● Hashicorp Nomad https://www.nomadproject.io/

20. Our data is safe
If we need to give our state to our container applications.
We have options depending on our design choices
● Kubernetes http://kubernetes.io/docs/user-guide/volumes/
● Flocker https://clusterhq.com/flocker/introduction/

21. This is how we protect ourselves from failure
Service discovery is the backbone to our container
schedulers. Service discovery dynamically updates the
locations of our containers as they move between compute
nodes.
● Consul https://www.consul.io/
● Etcd https://coreos.com/etcd/

22. How is my data structured
Dockerfile
● Base configurations for the container
● Arguments for runtime
● Live in it’s own git repo
Run time
● Volume, CPU, Mem constraints
● Runtime args
● Name of container

23. How is my data structured
CD/CI
● Unit test should live with the Dockerfile
Unit test can be written in various languages.
● Golang
● Ruby
● Python

24. Is this production ready

25. Let’s tie it all together
Kubernetes

26. Let’s tie it all together
Docker Swarm with Flocker

27. Let’s tie it all together
Mesos

28. Questions

29. About me
https://forge.puppet.com/scottyc
https://github.com/scotty-c
https://hub.docker.com/u/scottyc/
@scottcoulton
scottyc