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

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
5. None
6. None

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
13. None
14. None

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
22. None
23. None

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