We're succesfully using razor here at Blue Box.
We're using Fletcher's razor cookbook that Matt mentioned above.
We're using Fletcher's chef-broker.
We're also using Fletcher's safety_razor gem to control policy / node state via a sinatra app:
https://github.com/blueboxgroup/safety_razor
Basically we're using all the the razor stuff that Fletcher wrote while he worked here :)
We've been using it in production for about 3 months now and it's been working quite well.
We have an automated workflow where we
- request the sinatra app to setup a custom tag / policy association for the node we want to provision
- move a machine into the razor vlan
- powercycle it so that it netboots and razor can pick it up
- the node reimages according to it's policy and then is moved back into it's orginal vlan
- chef-broker takes over and bootstraps the node, using the run_list that get's determined by some of the tags that are indicated by the policy
There are some foibles with it:
- lack of security (basicaly assumes you are on not on the public internet)
- strange database tables that are very non-normalized, such that you end up have to delete multiple dependent objects when something changes underneath it. (mongo design artifact)
But all in all, we're happy with it.
Razor is going through a re-write right now. We look foward to their proposed imrovements which should help the database situation. The README on the main razor project goes into good detail on the rewrite:
https://github.com/puppetlabs/Razor
I'm realizing there is a blog post due on this subject and our workflow :p
Regards,
Sam
We use collins http://tumblr.github.io/collins/ as an asset db & state management tool, and cobbler to do the actual kickstart stuff.
This means that collins & friends care about provisioning related tasks: Is this hunk of metal burned working and counted for? Serial number? Rack location? DHCP configured? DNS? Which ks file to use?
The last thing the ks files do is install chef and then it's out of "provisioning" and into "configuration management". From there it probably doesn't look any different than any other use of chef. This means that we can treat nodes in chef as ephemeral and another system deals with stuff like keeping track of serial numbers for 3 years.
We use an ohai plugin to suck in all of the collins info for each node so chef can play with that too. That gives us some niceties like chef /etc/motd saying "YO THIS BOX IS BROKEN" when an asset is put into maintenance in collins.
On 09/04/2013 11:54 AM, Phillip Roberts wrote:
O 734.922.7014 | C 614.423.9871 | www.MyBuys.com<http://www.mybuys.com/>Does anyone have any good links or pointers to bare metal provisioning? I have done plenty of cloud based chef stuff, however, we want to now start managing all of our physical servers with chef as well. I am trying to replace as much of our build system as possible (ad hoc bash / perl scripts) for this provisioning. So I am looking for a good way to do this, I understand chef is not a PXE server, but just how far back in the tool chain can I go?
My thoughts are serving up a kickstart file (since we are a RHEL / Cent based shop) that builds just enough of the OS in order to hand off to chef.
Anyway, any pointers, or past presentations / links would be much appreciated.
Thanks,
Phillip Roberts | Sr. Linux Administrator
San Mateo | Ann Arbor | New York | London
[cid:image001.png@01CDDDEC.1264D1F0]
Archive powered by MHonArc 2.6.16.