The Devs are Ops-ing (and it isn’t painful)

Talk given at Ansiblefest London 2015

Transcript

1. The Devs are Ops-ing (and it isn’t painful) Ali Asad Lotia ali.asad.lotia@gmail.com @aalotia Blue Newt Software http://www.blue-newt.com
2. Who • Me • 15+ years wearing multiple hats • Build, deploy, maintain • Blue Newt Software • Driving simulators for Ford and Mercedes • Motion tracking systems used in sports and on factory floors
3. Original Team • 3-4 experienced full-time developers • Geographically distributed • Considerable C++, Python expertise • 1 member with production config management experience • No full-time ops
4. What • Motion tracking system • Factory floors • Real-time player tracking in major American Football league
7. Behind the curtain • Half rack at stadium • Bare metal • Many sites • Small # hosts/site • Intermittent connectivity
8. Starting out… • 0 - 7 Stadiums • Fast ramp-up • Remote deployment • Remote management
9. In the beginning…
10. “Automation”
11. Deployment: Pre Ansible tar.gz scp expand ssh manual startup
12. Issues • Manual builds • Large artefacts • Missed dependencies • Clashes with system versions • Manual Patching
15. The contenders • Puppet • Chef • Saltstack • Pallet • Ansible
16. Why not? • No resources for central servers • No assurance of connectivity • System specific client authentication • Learning curve
17. Why Ansible? • Simple • Agentless/Serverless • Written in Python • Batteries included • Community
18. Executable docs
19. Short feedback loop +
20. Ansible: The Early Days • Many tasks/role • RY not DRY • Early Ansible >> “the bash script”!
21. Enabled • Provisioning • Volumes • Filesystems • Base packages • Deployments • Dependencies • Components
24. Refinements • Role granularity • DRY-ing • Avoiding command, shell modules • Idempotence
25. –Delbert Cope, Viceroy of Development “We couldn’t have done it without Ansible.”
26. –Bob Kuehne, CEO “Ansible is boring, you don’t really think about… air. You just sort of know it’s there and it works.”
27. Ansible: Now • Dev setups (some) • Repurposed testing systems • 22 stadiums and growing • 2-3 machines / stadium • All engineers deploying to production
28. Challenges • Companywide Vagrant + Ansible dev setups • Using Python API • Spoiled by Ansible doc quality • Using Ansible Galaxy • Filtering by distro • Role quality
29. Ansible: The Future • Testing • HW RAID • Building containers • Deploying containers • Managing schedulers
30. Wrapping up • Unusual constraints • Compressed time frame • Evolving environment • Ansible FTW!
31. Finis • Thank you! • Questions? • @aalotia ali.asad.lotia@gmail.com
32. References • 6: Zebra Technologies Inc., James Arundis/Boston Globe Staff http://www.bostonglobe.com/business/ 2014/08/31/technology-tracks-players-speed-football-field/z0Kc736R3GJVBf7fQjg9JL/story.html • 13: ”Glazier tools" by Hans Bernhard (Schnobby) - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - 
 http://commons.wikimedia.org/wiki/File:Glazier_tools.JPG#mediaviewer/File:Glazier_tools.JPG • 14: "Professor Lucifer Butts" by Rube Goldberg - an old comic book. Licensed under Public Domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Professor_Lucifer_Butts.gif#mediaviewer/ File:Professor_Lucifer_Butts.gif • 19: Vagrant logo 
 http://commons.wikimedia.org/wiki/File:Vagrant.png#mediaviewer/File:Vagrant.png
 Ansible logo
 http://www.ansible.com/hs-fs/hub/330046/file-764918156-png/Official_Logos/ansible_circleA_black.png • 22: "Victorinox Multitool" by EvaK - private. Licensed under FAL via Wikimedia Commons - http:// commons.wikimedia.org/wiki/File:Victorinox_Multitool.jpg#mediaviewer/File:Victorinox_Multitool.jpg