1. Diving In
See what happens when a Java developer
tries to do DevOps
@awilmore Copper @ an Aussie Insurance Company
2. Disclaimer
Me: DevOps n00b
I’m really just here to learn (but Stephen’s making me talk!)
3. Overview
1. How Docker was introduced to the Copper team
2. The Copper build agents - Doing it Wrong!
3. New service opportunity - Doing it Right!
4. The challenges ahead
5. The Copper Team
• We are our company’s rapid software delivery team
• We are cross-functional,“innovative early adopters
of technology”
• Grails + AngularJS, plus many other technologies
• Provide a faster speed-to-market for customers
• Provide an alternative path to production for our
business
6. So… In the beginning…
Leo, Pete, Mike: DevOps expert consultants from Odecee
Their research project: Docker
Meanwhile…
Build Engineering Team had a problem:
Need more servers, for more Bamboo build agents!
8. Some Copper devs were still not happy…
“Too much job queuing in Bamboo!”
So I forked the Bamboo
build agents and created…
9. Grails-Dedicated Build Agents
…and six months on…
• Manually built, manually managed
• 3.5 GB on disk (way too big)
• Rebuilds mean re-download-the-Internet
• Too much hands on
Docker: Doing it Wrong!
10. Docker: Doing it Wrong!
• Containers simply do too much!
• Stateful and Stateless concerns mixed together
• Poor use of Dockerfiles and Image Layering
• No orchestration
42. Not so good
The next problem…
No orchestration
43. No orchestration
When I need some new agents…
[adam@laptop ~] ssh adam@build-server
Last login: Tue Oct 28 22:13:27 2014 from 10.126.176.99
adam@build-server:~ >>
cd git/buildeng-puppet
adam@build-server:~/git/buildeng-puppet >> git checkout grails-agents-branch
adam@build-server:~/git/buildeng-puppet >> docker build -t=“agent-11” .
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
---> e360b5673aef
Step 1 : MAINTAINER Adam Wilmore "adam.wilmore@abc.com.au"
---> Using cache
...
...
...
(a long time later...)
49. Doing It Wrong
• Containers simply do too much!
• Stateful and Stateless concerns mixed together
• Poor use of Dockerfiles and Image Layering
• No orchestration
Recap:
52. The Next Project
• Build new Artifactory* Service using Docker
• Find out a bit more about Docker in the process
• Take the learnings so far, build a bit, learn a bit
more, repeat…
* Artifactory from JFrog is an artefact management
tool, similar to Nexus
53. “Hang on a minute! How
do you know that Docker is the right tool
for this type of service?”
Good question.
59. Project Requirements
• Artifactory service comprised:
• Java app server (Jetty)
• Postgres backend
• Web-based file share
• Linux all the way down
• Performance and Availability are critical - can’t be
worse than previous artefact manager
60. Some Principles to Work With
• Use Puppet with Docker for “image creation”; and
• Favour Puppet over Docker for “doing work” *
• Stick to One Concern Per Container!
• Dive in and learn!
* Why? For reuse, “might move to EC2 one day”, already familiar with Puppet…?
61. “Hang on a minute! What about
service discovery, orchestration, logging,
monitoring and backups?”
<crickets…>
66. The State of Ops
• How do we scale and load-balance for performance and
availability?
• How do we backup all critical data?
• How do we do upgrades?
• How do we keep operational configuration changes under
source-control?
• Can we restore everything in the event of a disaster?
• What about service discovery, orchestration, monitoring, all that
stuff to help with some of these questions?
67. The State of Dev
• Have we correctly designed containers for extensibility?
• Are we using the right tools and libraries to build the
containers?
• How do we version and release our code changes?
• Is our code set up for optimal reuse?
• How do we test our builds?
• How do we collaborate most effectively as developers
writing infrastructure software?