Razor talk-2013-08-23

1,666 views

Published on

Over the past year, Razor has shown that there is huge demand for a policy-driven, discovery-based provisioning solution for bare metal and virtualized hardware. Simply put, Razor is the tool of choice to go from zero to fully-installed, including handoff to Puppet, in the most flexible and DevOps friendly way.

Based on our experience, we have revamped Razor significantly with an eye towards easier deployment and maintenance, more flexibility in describing the provisioning process, and more robust hardware support. This talk will explain what has changed (all the things that made Razor hard to deploy), what has stayed the same (all the cool features unique to Razor), and where we see Razor's journey going from here.

Published in: Technology
  • Be the first to comment

Razor talk-2013-08-23

  1. 1. Razor Provision like a boss David Lutterkort Principal Engineer | Puppet Labs @lutterkort lutter@puppetlabs.com
  2. 2. Who are you ? • Joined Puppet Labs in May • One of the first contributors to Puppet • Started Augeas • Apache Deltacloud, DMTF CIMI • email: lutter@puppetlabs.com • IRC: lutter, twitter: @lutterkort
  3. 3. Razor history • Started by EMC/VMWare • Nick Weaver, Tom McSweeney • EMC World 2012 • PuppetConf 2012
  4. 4. Ingredients • ipxe • Hardware discovery and inventory • Tagging and policies
  5. 5. Where is Razor going • Rewrite for different stack • Simplify deployment • Simplify maintenance • Simplify usage Don’t muck with the good bits
  6. 6. The more it changes ... • Node discovery with MK and facter • Use ipxe to control boot • Written in Ruby • Flexible tag/rule-based policy match • Simple handoff to Puppet • Manage large number of nodes
  7. 7. Foundations
  8. 8. Aside: Torquebox rules • Daemons • Scheduled Jobs • Messaging • Clustering • Integration with Java libraries • Java management
  9. 9. Components • Razor server • Razor CLI • Microkernel agent • Microkernel image • Razor UI
  10. 10. Microkernel • Separate MK agent from OS image • Build on EL • well-known hardware support • formal support offerings • currently ~ 150MB (unoptimized) • Enable alternative MK builds
  11. 11. Server API • JSON everywhere • Query objects with RESTful interface • Update/modify using commands (CQRS) • all changes happen async • Authentication [TODO]
  12. 12. CLI 1> razor nodes 2> razor tags mytag 3> razor create-tag --name=any --rule ‘[“=”, 1, 1]’ 4> razor create-image --name=... --image-url=... 5> razor create-policy --json policy.json
  13. 13. Tags • A named rule • Rules can have complex logic [“or”, [“in”, [“fact”, “macaddress”, “de:ad:be:ef:00:01”, “de:ad:be:ef:00:02”]], [“=”, “2”, [“fact”, “processorcount”]]]
  14. 14. Policies # policy.json { “name”: “fedora-for-any”, “image”: { “name”: “fedora-19” }, “installer”: { “name”: “fedora-base” }, “broker”: { “name”: “puppet” }, “hostname”: “host${id}.example.com”, “root_password”: “secret”, “max_count”: 20, “enabled”: true, “line_number”: 100, “tags”: [{ “name”: “any” }] }
  15. 15. Installers • OS installation inherently linear • Completely in metadata • file based or in DB • Simple node/server API • evaluate and fetch ERB template • store a value (e.g., IP address) • log a message
  16. 16. Installer example --- # redhat.yaml os: Red Hat Enterprise Linux os_version: 6 description: Red Hat EL installer boot_sequence: 1: boot_install default: boot_local
  17. 17. Template example # os_boot.erb hostname <%= node.hostname %> yum -y install rubygems facter [ $? -eq 0 ] && curl <%= log_url(“ok”) %> || curl <%= log_url(“fail”, :error) %> #!ipxe # boot_install.erb kernel <%= image_url(“/vmlinuz”) %> ks=<%= file_url(“kickstart”) %>
  18. 18. The road forward • Make release soon (~ 2 weeks) • Add lifecycle management features • Userdata for nodes • Node commands • Generate events
  19. 19. Possible node commands • Boot locally • Boot into MK • register • update facts • BIOS/firmware update • Reinstall OS • Unbind & run through policy table
  20. 20. Event generation • User-controlled actions (commands) • Possible events • node discovered • policy bound • installer finished • policy unbound
  21. 21. Demo time
  22. 22. Don’t be a stranger Github repos (will change) Server: https://github.com/puppetlabs/razor-server Microkernel: https://github.com/puppetlabs/razor-el-mk Mailing list http://groups.google.com/group/puppet-razor IRC: #puppet-razor (freenode) My email: lutter@puppetlabs.com
  23. 23. Thank You David Lutterkort Principal Engineer | Puppet Labs @lutterkort Collaborate. Automate. Ship.
  24. 24. Follow us on Twitter @puppetlabs youtube.com/puppetlabsinc slideshare.net/puppetlabs Collaborate. Automate. Ship.

×