[chef] Re: Chef Server vs. Not Guidance


Chronological Thread 
  • From: Torben Knerr < >
  • To:
  • Subject: [chef] Re: Chef Server vs. Not Guidance
  • Date: Wed, 5 Aug 2015 08:15:11 +0200

Hi Kelly,

on 2) + 3):

If you are happily using Vagrant for local development / CI already, you could also use it for describing your production setups in a multi-vm Vagrantfile and use the specific providers (eg vsphere, aws, rackspace etc). This works quite well as long as your infrastructure is static and you can describe it in terms of individual nodes, i.e. no autoscaling etc.

If you want to go a more cheffish route the chef-provisioning might be interesting for you.

I believe with either approach you can still use roles and environments. But not sure whether chef-provisioning works in solo / zero mode.

HTH, Torben 

Am 04.08.2015 21:24 schrieb "Kelly Brownsberger" < "> >:
My team has been developing recipes with Chef for several months now and we've made significant progress in automating our infrastructure, but we're now getting to a point where we need to scale this up and make it a first class part of our CI pipeline where many teams are maintaining their own cookbooks sitting side by side the software code that's running on this infrastructure.  Up until now we've been focused entirely on recipe development using chef-client and Vagrant for spinning up nodes and running the cookbooks via Vagrant's built in provisioners.  As you'd expect, things are starting to become unwieldy with managing attributes and common shared cookbooks, etc.  We've started looking at Berkshelf for managing dependencies and environments and roles for putting some structure to our attributes.
 
Here's where it gets interesting... to put it bluntly, there are several within my team that aren't bought into the idea of Chef Server.  Our entire enterprise orbits around our version control system.  And we already have a large investment in Artifactory which is a home for all of the technical artifacts for all of our products across several platforms and it works quite well as a general purpose distribution hub.  As we've started playing with the chef concepts of environments and roles while running chef-client in local mode, I think I see the value in these abstractions, however.... I'm starting to get the sense that using these outside the context of a Chef Server is going to be a very bumpy road.
 
Right now I'm able to get our cookbook using environments and roles and have chef-client find them by pointed to a directory on disk where these json files list under version control.  This works, but the next use case we're looking to support is running these outside the context of Vagrant and the current thought is using --recipe-url to point to a tarball that we published to artifactory from our CI builds in Jenkins (by way of Berks package).  This use case would be for running these cookbooks are production machines that do not have connectivity to our version control system and will not be running in the context of Vagrant.  As best I can tell, this will not work as I do not believe there is any way to include environments and roles json files in this tarbar and have chef-client recognize it via --recipe-url.  Can someone confirm my suspicion?
 
Questions
1) are roles and environments even recommended at all?  I'm finding folks out there that really feel strongly they are an anti-pattern [1][2], though I'm not sure I agree with them.
2) I keep hearing about how there are loads of people out there using chef without chef-server and doing so happily.  are there folks using environments and roles?
3) similar to environments and roles, how are nodes managed in a chef-server-less world?  I see that you can define these in json and even knife these into a chef server, but when I do a chef-client run in local mode, the nodes/ directory is written to with data from that run.  In other words files in nodes/ doesn't seem to be something that's considered a "source" of anything, but rather a runtime output dir.
4) I'm torn with chef-server because it feels like something like this shouldn't be necessary, but the deeper I get into these concepts more it feels like we're going against the grain not fully embracing chef-server.  Can anyone point me to some detailed information on what the full development production lifecycle would look liek with a chef-server oriented world?  What about the same in a chef-server-less world?
 
Sorry for the long rambling email, but was hoping some kind soul could give me some guidance on how to proceed - every direction we look right now feel less than ideal.
 



Archive powered by MHonArc 2.6.16.

§