Puppetconf 2013: Razor - provision like a boss

1,198 views

Published on

My talk about the current state of razor and the road going forward - find the code at https://github.com/puppetlabs/razor-server

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,198
On SlideShare
0
From Embeds
0
Number of Embeds
96
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Existing systems: get very personal with each server Need MAC Selection out-of-band
  • What happens when a node boots with Razor - TFTP -> Razor server - boot MK - checkin/facts - tag & apply policy - reboot into installer - hand off to broker
  • - Deploying easy & well understood - Setup Postgres - gem install ...
  • Application server for Ruby Support for Sinatra/Rails apps jRuby JBoss AS Install from gem (~ 60MB)
  • Control what gets installed match nodes and policies using tags Tie various objects together image/installer some metadata (hostname/root password)IP address pool [TODO] max. count
  • Puppetconf 2013: Razor - provision like a boss

    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.

    ×