Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Migrating from another configuration management system

Migrating from another configuration management system

Learn at a high level what it takes to move your existing configuration management to use Ansible. Shows how to get your feet wet, plan your migration, and execute the rewrite.

Robby Colvin

October 22, 2013
Tweet

Other Decks in Technology

Transcript

  1. About Me • Work @ Kiip • Software Engineer •

    Operations Engineer • Engineer
  2. Why choose Ansible? • Application Deployment • Cloud-aware orchestration •

    Ad-hoc tasks • Low barrier to entry stack-wise • Simple for developers to grasp • Python + Boto • No central server required • Flexibility
  3. Is it right for you? • Is it cost-effective? •

    Does it fit your culture? • Does it align with your goals? • Can you abandon your current tooling? • Does it improve productivity?
  4. Ansible 101 • YAML • Jinja2 • Hosts • Roles

    • Playbooks • CLI • Modules
  5. Modules • Builtin • EC2, DigitalOcean, Rackspace, Linode, et. al.

    • Commands • Databases • Files/Templates • Packages • Etc.
  6. Get Your Feet Wet • Several options to start with

    Ansible • Risk free™ • Pick a simple role
  7. Get Your Feet Wet • Several options to start with

    Ansible • Risk free™ • Pick a simple role • Take baby steps
  8. Get Your Feet Wet • Several options to start with

    Ansible • Risk free™ • Pick a simple role • Take baby steps • Simple Module(s)
  9. Get Your Feet Wet • Several options to start with

    Ansible • Risk free™ • Pick a simple role • Take baby steps • Simple Module(s) • Build on what you learn
  10. Configure # ansible.cfg [defaults] hostfile = production.ini private_key_file = production.pem

    remote_user = ubuntu sudo = True [ssh_connection] scp_if_ssh = True
  11. Existing Boxes • CLI • --check --diff • Push from

    your machine • Run simple modules: ping, setup, etc. • Move on to other modules
  12. Vagrant • Run from your machine to Vagrant host •

    Use Ansible provisioner • Go crazy • Simulate multiple hosts, clusters, etc.
  13. Ansible Vagrant host # vagrant.ini 192.168.33.10 \ ansible_ssh_user = vagrant

    \ ansible_ssh_private_key_file = \ ~/.vagrant.d/insecure_private_key
  14. Take stock • Identify existing cruft • Get to know

    Ansible modules (don't re-invent the wheel) • Identify custom modules to be written • Integrate with infrastructure • Get to know the documentation • Learn how to use the CLI • Learn how to write Jinja2 templates
  15. Host Inventory • Write inventory by hand • Use ec2.py

    • Write your own inventory script
  16. Start the rewrite • Baby steps: one role at a

    time • Use --check --diff • Test against staging or box outside LB
  17. Start the rewrite • Baby steps: one role at a

    time • Use --check --diff • Test against staging or box outside LB • Vagrant
  18. Start the rewrite • Baby steps: one role at a

    time • Use --check --diff • Test against staging or box outside LB • Vagrant • Write new roles/playbooks in ansible
  19. Start the rewrite • Baby steps: one role at a

    time • Use --check --diff • Test against staging or box outside LB • Vagrant • Write new roles/playbooks in ansible • Get everyone involved
  20. Start the rewrite • Baby steps: one role at a

    time • Use --check --diff • Test against staging or box outside LB • Vagrant • Write new roles/playbooks in ansible • Get everyone involved • Stay up to date with documentation
  21. NONE! • If done properly, you should be good to

    go • Just iterate and continue forward • Move on to advanced topics