Ansible

Ansible is an open source, model driven, configuration management, deployment, and ad-hoc task execution framework for managing Linux/Unix operating systems. http://ansible.github.com/

Transcript

1. ANSIBLE Radically Simple Configuration & Deployment Michael DeHaan
2. PREPARE FOR TRANSPORT
3. but first a little bit about me...
5. • IBM (Storage) • Motorola (Server/Embedded Stuff) • Red Hat (Cobbler, 1/3 of Func, Cloud...) • Puppet Labs (Product Mgmt) • rPath (API, Cloud...) • shot all photos in this presentation :) michaeldehaan.net
6. So...
7. In the Beginning There Was The Command Line
8. And Everybody Wrote Shell Scripts
10. This Was A Lot Of Work
11. ...It Got Better...
12. CFEngine
15. ...Then It Got (More) Better...
16. Puppet
17. Strong Resources Support
18. ...But Too Complex Of A Language...
19. Chef
20. Uses Ruby To Replace Puppet Language
21. Polarizing, not everyone likes Ruby
22. Both Are Very “Configuration Focused”
24. And also can be a pain to write “code” for and test
25. Hard to tell what the scripts you write are actually going to do...
27. and Configuration is NOT All You Need To Do
28. What About...
29. “Do This Now, Just Once, Fast!”
31. Initially, SSH Loops
32. Predates All of the Above
34. then pssh, etc
36. But these weren’t API oriented enough for some of us
37. Enter Func (I wrote part of this)
39. and numerous clones
40. (These Are Cool Because You Can Build Applications On Top Of Them)
41. But sometimes bad because they undo the work of the config system.
42. WAIT!
43. We Also Need To Push Software Releases!!!
45. Various Attempts...
46. Typically Liked By Webapp Developers
47. Disliked By Sysadmins
48. (Disregard for packaging, don’t track deps, tools can undo work of other tools)
49. Capistrano
50. Fabric
51. Still Complicated...
52. Very specialized
53. And Multi-Tier Deployment?
54. Various Attempts, None Very Good
56. Fragile. Didn’t Learn Lessons from Config Tools.
57. TO REVIEW
59. We (Apparently) Need Three Different Classes of Solutions:
60. (1) Configure (2) Deploy (3) Ad-Hoc Tasks
61. As A Result, We Are Chained To Multiple Automation Systems
63. This Makes No Sense
65. Any Way Out?
67. DevOps tools have become painful to use
69. Knowing The Obscure Idioms To Do X & Y May Initially Seem Fun
70. Because It’s Like Programming, Which Is (Sometimes) Fun
71. But It’s Slow To Implement
73. And It’s Only Fun Until Someone Gets Hurt
75. HOW HAVE WE GOTTEN INTO THIS GIANT RABBIT HOLE?
77. Why Do I Need Software Tests for My Infrastructure?
78. I have other things to do than support this mess.
80. WE NEED TO RESET
81. We Are Drowning In Complexity
83. I want one tool to manage all the things.
84. Automation should not require programming experience.
85. I Shouldn’t Be Chained Down By Tools That Are Hard To Learn, Use, & Debug
87. Automate in English.
89. Lock And Load
91. It Can Still Be Fun.
93. Simpler Tools Mean Easier Collaboration
95. Configuration, Deployment, Ad-Hoc Tasks -- All in One Tool
97. Idempotent Resources (yeah, we still like those)
98. Multi-tier Deployment Designed For Large Web Installations.
99. POWER.
101. FAME. MONEY.
103. Ok, we can’t promise that, but we can promise...
104. 1/60 the amount of source code of related config tools
105. No servers or databases to set up and maintain
106. No daemons to fall over
107. Extensiblity in ANY programming/scripting language
108. Get going in MINUTES
109. A Really Powerful API
111. A Minimal, Easy To Use Config Language
113. Ad Hoc Task Support
114. ansible clusterXYZ -a “/ sbin/reboot -t now”
115. More Time For Stuff That Matters
116. A Simpler Path
118. Results.
119. ansible.github.com