razor talk-2013-08-23
TRANSCRIPT
RazorProvision like a bossDavid LutterkortPrincipal Engineer | Puppet Labs @[email protected]
Who are you ?• Joined Puppet Labs in May
• One of the first contributors to Puppet
• Started Augeas
• Apache Deltacloud, DMTF CIMI
• email: [email protected]
• IRC: lutter, twitter: @lutterkort
Razor history• Started by EMC/VMWare
• Nick Weaver, Tom McSweeney
• EMC World 2012
• PuppetConf 2012
Ingredients• ipxe
• Hardware discovery and inventory
• Tagging and policies
Where is Razor going• Rewrite for different stack
• Simplify deployment
• Simplify maintenance
• Simplify usage
Don’t muck with the good bits
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
Foundations
Aside: Torquebox rules• Daemons
• Scheduled Jobs
• Messaging
• Clustering
• Integration with Java libraries
• Java management
Components• Razor server
• Razor CLI
• Microkernel agent
• Microkernel image
• Razor UI
Microkernel• Separate MK agent from OS image
• Build on EL
• well-known hardware support
• formal support offerings
• currently ~ 150MB (unoptimized)
• Enable alternative MK builds
Server API• JSON everywhere
• Query objects with RESTful interface
• Update/modify using commands (CQRS)
• all changes happen async
• Authentication [TODO]
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
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”]]]
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” }]}
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
Installer example---# redhat.yamlos: Red Hat Enterprise Linuxos_version: 6description: Red Hat EL installerboot_sequence: 1: boot_install default: boot_local
Template example
# os_boot.erbhostname <%= 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”) %>
The road forward• Make release soon (~ 2 weeks)
• Add lifecycle management features
• Userdata for nodes
• Node commands
• Generate events
Possible node commands• Boot locally
• Boot into MK
• register
• update facts
• BIOS/firmware update
• Reinstall OS
• Unbind & run through policy table
Event generation• User-controlled actions (commands)
• Possible events
• node discovered
• policy bound
• installer finished
• policy unbound
Demo time
Don’t be a strangerGithub repos (will change)Server: https://github.com/puppetlabs/razor-serverMicrokernel: https://github.com/puppetlabs/razor-el-mkMailing listhttp://groups.google.com/group/puppet-razorIRC: #puppet-razor (freenode)My email: [email protected]
Thank YouDavid LutterkortPrincipal Engineer | Puppet Labs @lutterkort
Collaborate. Automate. Ship.
Follow us on Twitter @puppetlabs
youtube.com/puppetlabsinc
slideshare.net/puppetlabs
Collaborate. Automate. Ship.