Shipping With Snakes

An non-practical introduction to Ansible for developers.

Transcript

3. This is my dog. He’s a good boy. Let’s now go on a walk with him down The Brief Path of Configuration Management History. We want to discuss the basic “divide” of CM and Orchestration tools
4. puppet, cfengine, terraform are examples of declarative languages. They involve lots of “behind the scenes” magic to present a simple interface to the user that hides how the sausage is made. In some cases this is good, often times it’s limiting if the language isn’t expressive or mature enough to handle most use cases. These things often sprawl into their own languages. Look for focused intent and scope or unification of different items into a common (and better) language.
5. puppet, chef, fabric, etc.. are procedural (or imperative) tools that assume the user knows better than the automation how to achieve a particular task given the users current constraints. Often these tools will be called “down and dirty” because they are by nature more utilitarian that declarative tools. In this case one can (and should) look at these tools as “augmentation frameworks” for rather than “configuration management” in the more traditional sense. Idempotent operation is a large key to success because it allows for stateless operation, albeit with more overheard for repeated checking.
6. It’s a deployment methodology! It’s a cultural phenomenon! It’s service-centric tooling with instrumentation! It’s.. whatever. In the end, DevOps is about being a decent human with a sense of professionalism and understanding what works for your situation. Since situations change so should you and your tools. Ansible works well in DevOps spaces because it’s flexible enough to work through changing environments along with you.
7. Your CEO doesn't care about configuring servers, and neither does Ansible. Ansible provides automation capabilities for all your stuff to help you deliver value faster and more consistently. It’s a procedural tool with a good sense of idempotency. It can talk to almost anything and configure most aspects of whatever it can talk to using modules. When you need to extend it, it is easy to do so. It can orchestrate a complex app deploy or setup 802.1x auth on a switchport and everything in between. And duh, it’s written in Python.
8. This slide intentionally left vague. The rest of this presentation will be a broad but shallow introduction to Ansible.
9. Inventory is basic first step to using ansible. Defines remote hosts, group membership, and specific per-host vars/settings (alias, password, username, etc..). Can have per-host vars here, don’t recommend it. Minimal inventory is just “localhost” http://docs.ansible.com/ansible/latest/intro_inventory.html
10. adhoc command is useful for spitballing and basic testing. Lets you run any module in ansible against remote hosts. Also useful for more easily doing common tasks like restarting services, removing files, etc.. I also use it as a “parallel ssh” when checking on distributed systems (Eg: “Do you all agree on leader?”) or when a transition from state to state needs manual assistance (Eg: service upgrades that require an extra step “just” this once) http://docs.ansible.com/ansible/latest/intro_adhoc.html
11. Under the covers, ansible does some nifty stuff. The system running ansible is known as the control node. This node then ssh’s to each remote host, makes a copy of the module being run on the remote host, runs it, collects the output, and removed the file. It does this loop for each host and each task. In this case, “ssh” acts as the transport, and the “agent” is whatever ephemeral files we send over. This makes it easy to get started with and accessible to anyone with python and ssh.
12. Super simple playbook. This sets up one play in the book, the play has one task. Only the pip will be executed on the remote machine, everything else is local to the control node. Plays allow you to chain tasks together and playbooks allow you to consolidate plays into one book. One playbook is one file (fsvo one). Roles, includes, pre_ and post_ tasks can add additional tasks. Files are YAML and use jinja templating like all yams files in ansible (think pre-processed, more on this in a bit) Plays in playbook usually accomplish a goal (deploy app, configure machine, create a VPC, etc..). Each play leave things ready for the next. Targeting plays can be done with tags or conditionals (when:). State is reset between plays (registered vars are dumped, facts are forgotten, etc..) except for host state. Hosts that fail in a prior play are removed from the
13. Look Ma, no hands! Noticed skipped and ok on tasks. We can also see changed and failed.
14. Roles are “exploded plays” that are designed for code reuse. They can be called from plays and are run before tasks. Roles should be isolated to one “aspect” of a system (eg: “this system runs nginx”) and normally be normalized sufficiently to not be specific to any one app. Later app roles or the tasks/plays in a playbook would further refine the state/config for the app specifically (eg, add in a nginx config) Roles can be included, that syntax is new and is changing in 2.3 and 2.4, please be sure to read the docs. http://docs.ansible.com/ansible/latest/playbooks_reuse_roles.html
15. Role usage in a playbook example. Roles can take conditionals which are applied to all tasks in the role, as well as parameters. By default roles can only be called once in a play, if you need to call a role multiple times adjust the meta “allow_duplicates” key to be true http://docs.ansible.com/ansible/latest/playbooks_reuse_roles.html
17. Let’s take a quick look at YAML syntax, variables, and control structures in ansible. As we go in, please remember ansible does not present a DSL for you to use nor is it a complete programming language. If something starts looking complicated / impossible, you probably need to step back and look at how to make the problem simpler. Also important to note that all of this logic processing happens on the control node, note the remote host.
18. SO MUCH INFO ON VARIABLES, READ THE DOCS SEVERAL TIMES. In short variables can be set in many locations, how you use them is a matter of personal taste and your environment. Don’t use all of them, pick a few that work for your workflow. Facts are auto generated for each host (can also use facter or ohai if installed) at the start of each play. By default they are not cached, but that can be setup via redis or JSON file. Notable since if ansible hasn’t “talked” to a host to gather facts, some data structures will be weird because hosts will be missing. If you do a lot of orchestration across multiple nodes, it pays to have fact caching setup. http://docs.ansible.com/ansible/latest/playbooks_variables.html
19. Jinja is a python tempalting lanagaige, and how ansibel actually uses variables in YAML files. Originally was used as a pre-processor, now is integrated into the parse engine. Older tutorials may have some weirdness here to work around the fact variables were then interpolated at parse time instead of at execution time now. Thing to know now is use quotes, then curly braces. Whitespace inside doesn’t matter. Yes, you can also use Jinja control structures. I consider this an antipattern, ansible gives you logical controls. http://docs.ansible.com/ansible/latest/playbooks_templating.html
20. http://docs.ansible.com/ansible/latest/playbooks_filters.html http://jinja.pocoo.org/docs/2.9/templates/#builtin-filters
21. Sometimes you don’t want to run a task (in a play, in a role, wherever) for whatever reason, in these cases you want to skip them and can do so with a conditional. Conditionals are jinja expressions and the context of the value is already in jinja, so no basic quotes or curly braces required. Only need them if you want your expression to be preprocessed with variable interpolation because evaluation. Note that when: is a ansible construct that is applied to all modules. It can also be applied to roles as well, in that case the when: conditional is silently appended to all tasks. When is basically a wrapper around “if X is true then do this Y” http://docs.ansible.com/ansible/latest/playbooks_conditionals.html
22. Loops allow you to loop on a data structure per host. Each iteration updates a new var called “item” made for that task. You can use it whoever in the module call and since it is a variable it can be as such, including using jinja filters, using it when: conditionals to skip some loop iterations, etc.. The value of “item” depends on the with_ function being used and the data structure it is being used on. with_list is the most common because lists preserve ordering, and a list of dicts is a fairly common design paradigm because it can be iterated using with several different with_ iterators on the same data structure http://docs.ansible.com/ansible/latest/playbooks_loops.html
23. http://docs.ansible.com/ansible/latest/playbooks_loops.html
24. This is a 2.0 feature to allow finer grained control over failure modes (versus just a full stop leaving you with a possibly unknown and inconsistent across fleet intermediate state). Since it is a language construct to ansible, not a module, it also gets become, become_user, when, etc.. for free, like a task. does not with with loops yet, that is open bug, unsure ever will (can use a role with repeated calls in these cases) http://docs.ansible.com/ansible/latest/playbooks_blocks.html
27. http://docs.ansible.com/ansible/latest/dev_guide/index.html
29. http://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html http://docs.ansible.com/ansible/latest/intro_dynamic_inventory.html
30. http://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html http://docs.ansible.com/ansible/latest/dev_guide/developing_program_flow_modules.html